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METHOD FOR ISSUING AN ELECTRONIC IDENTITY 

BACKGROUND OF THE INVENTION 

Field of the invention 

The presenc invention relates to electronic 
identity tecnniques and methods. More particularly the 
present invention relates to a novel and improved 
method and system for requesting and issuing an elec- 
tronic identity based on previously certified elec- 
tronic Identity, 

Description of the Prior Art 



With respect to securing communication, enti- 
ties are often required to electronically authenticate 
themselves before utilizing services or executing 
transactions. This authenticity may come m the form of 
a username and password combination or a certificate. 
To accomplish this feat, these entities must first reg- 
ister their existence either physically or virtually so 
that they might receive a proof of identity. 

Providing the proof, such as a username and 
25 password combination, carries out the actual authenti- 
cation. Aforementioned simple authentication schemes 
are unfortunately quite context specific: identity 
based on username and password may be totally insig- 
nificant in all other circumstances. Moreover, such 
30 proof does not irrefutably distinguish different enti- 
ties . 

Digital certificates or electronic identities 
are electronic files that are used to uniquely identify 
people and resources over networks such as the Inter- 
35 net. With help of digital certificates it is possible 
to make secure, confidential communication between two 
parties. When one travels to another country, his/her 
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passporc provides a universal way to establish your 
xdencicy and gain entry. Digical cercificaces provide 
similar idencxf ication. Certxf icaces may be issued by a 
crusced third parcy (TTP) such as a Cercificacion 
5 Auchoriny (CA) . Much like che role of che passporc of- 
fice, the role of rhe trusted third parcy is to vali- 
date the certificate holders' identity and to "sxgn" 
the certificate so that xt cannot be forged or campered 
with. Once a TTP has signed a certificate, the holder 
10 can present their certificate to people, Web sxtes, and 
network resources to prove chexr identity and establish 
encrypted, conf idenc ial communicat xons . 

A certificate typically includes a variety of 
information pertainxng to its owner and to the TTP that 
15 issued it. This xnformation can be as follows. The name 
of the holder and other identification information re- 
quired to uniquely identify the holder, such as the URL 
of the Web server using the certificate, an indivxd- 
ual's email address or the holder*s public key. The 
20 public key can be used to encrypt sensitive information 
for the certificate holder; the name of the Certifica- 
tion Authority that issued the certificate; a unique 
identifier; the validity period (or lifetime) of the 
certificate (a start and an end date) . 
25 In creating the certificate, this information 

is digitally signed by the issuing TTP. The TTP ' s sxg- 
nature on the certificate is like a tamper-detect xon 
seal on a bottle of pills - any tampering with the con- 
tents is easily detected. Digital certificates are usu- 
30 ally based on public-key cryptography, which uses a 
pair of keys for encryption and decryption. With pub- 
lic-key cryptography; keys work in pairs of matched 
■'public*' and "prxvate" keys. In cryptographic systems, 
the term key refers to a numerical value used by an al- 
3S gorithm to alter information, making that information 
secure and visible only to individuals who have the 
corresponding key to recover the information. 
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The public key can be freely discribuced winh- 
ouc compromising che privace key, which must be kepc 
secrec by irs owner. Since chese keys only work as a 
pair, an operation (for example encrypcion) done wich 
Che public key can only be undone (decr-ypced) wich che 
corresponding private key, and vice-versa. A digital 
certificace securely binds your identity, as verified 
by a trusted third party (a CA) , wich your public key. 

A CA certificate is a certificate that identi- 
fies a Certification Authority. CA certificates are 
just like other digital certificates except that they 
are self-signed, CA cercificacea are used no determine 
whether to crust certificates issued by theCA. 

In Che case of a passport, a passporc control 
officer will verify the validity and authenticity of 
your passport and determine whether to permit you en- 
try. Similarly, the CA certificace is used to authenci- 
cace and validate the Web server certificate. When a 
Web server certificace is presented to a browser, the 
browser uses the CA certificate to determine whether to 
crust Che Web server's certificate. If the server cer- 
tificace is valid, the secure session proceeds. If the 
server certificate is noc valid, the server certificate 
is rejected and the secure session is stopped. 

In digital environment the contemporary 
equivalent of an identity card is a certificate: a con- 
firmed proof of an entity's distinct identity. A cer- 
tificate typically does more than just confirms attrib- 
utes of its subject. The most corrunon use of (public 
key) certificates is to bind an entity's public keys to 
its identity. These keys can be used to various pur- 
poses such as providing authentication, authorization, 
confidentiality, integrity, or non- repudiation. 

Theoretically certificates are noc conte:x:t 
specific but in practice different uses require differ- 
ent certificates. E.g. standard X.509 certificate does 
not include e-mail address information that is required 
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m secure eleccronic mail (e,g. PGP or S/MIME) . Simi- 
larly other applications may need to have cheir own 
proprietary attributes included in certificates. Al- 
though this inclusion of attributes is not problematic 
5 per se, new certificates need to be created, 

US patent 5,982,898 describes a method for is- 
suing a short term certificate for a person who already 
has a previous certificate. The new certificate is is- 
sued after the validation process of the ownershin of 

10 the previous certificate. The validation is done by 
separating the tasks of identity verification and cer- 
cificace issuing, which allows a disassoci^c ing of che 
long-term binding between the person and his/her pub- 
lic/private key pair. This is accomplished by a regis - 

15 tration authority issuing a password to the person once 
it is satisfied of person^ s bona fide. Thereafter, 
whenever the person wishes to have a new certificate or 
eleccronic identity, the person contacts a certifica- 
tion authority, identifies itself with the password and 

20 obtains a certificate. The certificate typically in- 
cludes person's name and a public key m plaintext, and 
a signature. The signature is derived by hashing the 
plaintext portion of the certificate to obtain a value, 
and encrypting the value with the CA's private key. 

^5 In order to get a certificate or some other 

electronic proof of identity a subject must prove and 
register its existence to some authority. If the same 
identity needs several proofs for different uses, this 
repeated registration procedure would become quite in- 

3 0 convenient. 

SUMMARY OF THE INVENTION 

The purpose of this invention is to provide 
35 means to use a previously certified identity to create 
another representational form for the same identity. 
This representational for can be expressed as an elec- 
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croaic idenritry, a cercif icace, or a cercx f ican ed ac- 
cess CO a ser-y^ice or a server. This way an encicy, zhaz 
can be defined as a recipient of a eleccronic iden-icy 
or a cercificace or a holder of a cercificace, can ex- 
cend his, her or ics already verified idencicy for 
onher uses. The previously certified idencicy can be 
for instance so called mobxle idennitiy which is associ- 
ated CO a person's mobile terminal such as rriobile 
phone. The person can show co certificate be his/her 
own by using the digical signature feature of che mo- 
bile terminal. 

In che following is an example of che steps ot 
the identity extension process according to the present 
invention. Note rhac the entities and devices in the 
15 process descripcion are lisced by their role and may 
not be distinct ones in practical implementations. 

An entity needs to be authenticated in a con- 
text where it does not have a previously confirmed 
identity. The entity or authorized representative sup- 
20 plies optional information that is appended to verified 
facts provided by registration authority that knows the 
entity's mobile identity. 

This information and an identification request 
is sent to che mobile identity registration authority 
25 with routing info to the receiver of identification and 
also to the terminal equipment that contains the means, 
i.e. signing keys to prove the previously confirmed mo- 
bile identity. Based on identification request type 
registration authority appends optional sender-supplied 
30 attributes to verified data that it possesses and for- 
wards these to the specified terminal equipment. If the 
identity cannot be resolved from the terminal routing 
info, the process terminates. 

The entity or authorized representative in- 
35 spects the accuracy of identification response informa- 
tion on the terminal equipment and if he, she, or it is 
satisfied with it, digitally signs the response after 
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Which ic is senc back co regiscracion auchoricy. if 
idencif icacion type reguxres addicional guarancees 
e.g. cercif icacion, regiscracion auchoricy acquires ao- 
propriace coneirmacion from providers of chose serv- 
ices. Confirmed idencicy informacion is senc co che re- 
ceiver address specified in che original idenc i f icac ion 
requesc . 

Compared co previous regiscracion and cercifi- 
cacion schemes che mosc obvxous benefic xs chac che 
present invention offers che same amounc of cruse chac 
a local regiscracion office is capable of providing 
wichouc 1C3 physical and ocher conscraincs. The equiva- 
lence of cruse holds on condicion chac che regiscracxon 
auchoricy possesses or has access co corresponding m- 
15 formacion, i.e. ics privace databases or dacabases of 
ocher auchoricies such as Finnish Populacion Regiscry 
Cencer. On che ocher hand chere are also accribuces, 
such as access co a certain e-mail address, chac can be 
confirmed by virtual means even if these are not re- 

2 0 corded in advance. 

If mobile identity and equipment is used in- 
stead of e.g. a cerrainal equipped with a smart card 
reader, che solucion of che present invencion is co- 
cally locacion independenc . An encicy can confirm ics 

25 xdencity and acquire a new idencicy whenever and wher- 
ever ic is required and is not constrained by che 
available hardware and sofcware provided that the re- 
cipient is capable of receiving the affirmation. Al- 
though the solucion does not disallow the use of public 

30 mobile terminals (i.e. somebody else's phone}, mosc 
likely che terminal that is used in authorizing che 
idencif icacion response is an encicy 's own. Conse- 
quently an encicy is not required co perform sensitive 
operacions, such as encering a signing pin, on dis- 

3 5 crusced devices. 

Essencially che invencion is intended for ex- 
tending an entity's identity based on an existing 
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bile cercificare and onher verified and confirmed 
faces. The one of che mosc apparent and practical func- 
tions is CO use this information to issue new certifi- 
cates for various uses such as secure e-mail, PGP or 
5 S/MIME, The mobile variant of the solution, however, 
does not have to be as limited. Since the ability to 
provide confirmed facts about an entity is totally mo- 
bile, in certain situations certificates are not a key 
issue. Say, if mobile identity registration authority 
10 has access to Finnish Population Registry Center's da- 
tabase it can provide confirmed home address, marital 
status, or whatever is required, 

BRIEF DESCRIPTION OF THE DRAWINGS 

The features, objects, and advantages of the 
present invention will become more apparent from the 
detailed description set forch below when taken in con- 
junction with the drawings wherein; 

'FIG. 1 is a block diagram of a system of the 
present invent ion ; 

FIG, 2 is a flow diagram in accordance with 
one embodiment of the invention; 

FIG. 2 13 a second flow diagram in accordance 
with one embodiment of the invention 

DETAILED DESCRIPTION OP THE PREFERRED EMBODIMENTS 
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Figure 1 presents one example of the preferred 
30 system according to the present invention. The system 
of figure 1 includes mobile station MS which is con- 
nected through the communication network CN to the Cer- 
tificate Authority CA server. Also the system includes 
a terminal including for instance a web browser. The 
3 5 terminal is connected through the communication network 
CN to the server of CA. The mobile station contains 
means for digital signing a message or character 



8 



10 



15 



string, Digxcal signing means are certified wich at 
lease one cercificane which enables che user co auchen- 
ticace more cercif xcaces . This previous certificace can 
be a mobile cercificace which is mencioned above. 

Referring further to figure 1 it is described 
one preferred solution of the present invention. This 
solution rs described in the context of certifying a 
new PGP key pair. 

In this solution the following assumptions are 
made. The mobile phone's SIM card-signed PGP key packet 
only "lives" for a short time (a few minutes) in the 
system and is then thrown away. If it is logged it can 
be used for journalizing the transactions m the issu- 
ing process. Also it can be logged perhaps for keeping 
track of errors. If there were to be any permanent re- 
tention of this packet Cfor legal or other purposes) , 
it would have to comply with some existing standard 
format, in order to be assured that it could be ac- 
cessed and correctly interpreted in the future. 

described here, the format of the phone - 
signed PGP key packet does not fit any existing stan- 
dard. If necessary, a standard format could be de- 
signed, and the SIM card software would be required to 
create signatures . in this format. The user has control 

2 5 (physical security) of the PC and corresponding PGP 

private key used for performing che operations de- 
scribed here. The CA operates a publicly accessible PGP 
keyserver containing all of the PGP keys that the CA 
has signed. 

Here we describe the steps to follow in order 
to use the applicants S3 system to securely sign a PGP 
key by the WPKI CA (WPKI, Wireless public key infra- 
structure), using a user's S3 SIM card to link the sig- 
nature back to the proof of identity that was presented 

3 5 to the WPKI Local Registration Authority. This process 

is performed without breaching the anonymity of the 
user's SIM card Network ID. As described here, the pro- 
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cess is scaceiess on the CA end, reducing complexicy 
and increasing resiliency of the prococoi for the CA. 

At first software using PGP on the PC displays 
the name and PGP key fingerprint of the user chac is no 
be certified on the PC screen. Also displayed on che Pc 
display is a prompn to enter the 4 digit number on che 
mobile phone display. 

The PGP key fingerprint is a crypcographical ly 
scrong hash of che key. PGP users are accustomed to 
verifying keys by comparing key fingerprints, so this 
makes it easier to verify che PC-Phone link is reli- 
able, and not being attacked by an intruder inserting a 
fake message co be signed by the phone. The latter is 
probably not necessary co protect against, since we as- 
15 sume physical security for that link. However, che link 
is noc necessarily secured. 

The PC software communicates with the phone 
through the wired or wireless interface or other appro- 
priate interface, and passes a message packer (TBD) 

2 0 containing a command to start the PGP key signing proc- 

ess. Phone generates and displays a four digit random 
number, along with a prompt to type this number into 
the PC if the user wants to sign his PGP key with his 
phone key. 

The phone displays a 4 digit random number 
that Chen muse be manually entered into the PC's key- 
board. This prevents a daring (high probability of de- 
tection) accack from a hoscile device that might be 
communicacing with the phone, and trying to trick it 

3 0 into signing a "What is my name?" message that could be 

used to compromise the NID's anonymnity. 

Then user types in the 4 digit nunaber from the 
display on the phone into the PC, as requested by the 
screen prompt . 

Ori the PC, the software cakes the 4 digit ran- 
dom number entered by che user, and sends it with a 
message, intended co be sent to the CA, requescmg 
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(from Che CA) a User ID lookup for a phone NID nhac 
signed che requesc . In ocher words,' a "Whac my 
name?" request:. 

The phone compares the random number sent wich 
Che "Whac is my name?" request:, and if it macches, dis- 
plays a warning chat it is abouc co sign a PGP key wich 
i c s key . 

PC displays a lengchy legal nocice to user, 
warning trhac user is abouc co sign cheir PGP key wmh 
che phone's key and chac che user is concraccually ob- 
ligaced co only make chxs signacure if he is the owner 
of boch keys. Again, if che random number matched, che 
"What is my name?" message is signed by che phone, re- 
turned to che PC chrough che serial interface, and 
saved for transmission co che CA. The PC software gen- 
eraces another message, intended for transmission co 
che CA, this message contains the key fingerprint, and 
a request to the CA to sign the attached key, if the 
fingerprint matches. This is a "Sign this User ID and 
key, please," request. The "Sign this User ID and key, 
please." message is then passed co the phone chrough 
che serial interface, wich a request that che phone 
Sign the packet, using che ics SIM card private key. 

The PGP key fingerprint is displayed on che 
phone at this point and verified by the user to be in 
agreement with the PGP key fingerprint on the PC 
screen. The user is prompted to OK the signature, if 
the fingerprint matches. The User's phone sends the 
signed "Sign this User ID and key, please." packet back 
through the serial interface to che PC (along withi che 
phone key ID that signed it] . Save on che PC for lacer 
transmission co che CA. The PC-Phone conneccion is no 
longer needed afcer this point, and is dropped. 

Note that if desired, che process described in 
the preceding few steps could be accomplished with only 
one signed message from the phone. This message would 
contain a signacure of che PGP key fmgerprinc. The one 
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message would be used with two different meanings 
first to ask the CA, "What's my User* ID {name)?v and 
second to command it to "Sign this Key and User id 
please". In the first case the PGP key fingerprint xs 
ignored, since only the phone's NID is need to specify 
what name is desired from the CA. 

The PC opens up a secure channel (using TLS) 
to the Certification Authority, The PC sends che SIM- 
signed request for User ID ("What^s my User ID and 
name?") query to the CA over the secure link. 

The CA looks up the phone's owner m the con- 
fidential database, and sends the User ID for the phone 
back to the PC, as requested. This is che WPKI User ID 
that the phoneys owner had certified at che LRA. Send- 
15 ing this information to the PC does not breach the ano- 
nymity of the NID, since the link is encrypted and the 
phone owner is the one making the request. 

The PC checks to see If che returned WPKI User 
ID is present on the users PGP key. If xt is, then the 
20 process proceeds to the next step, automatically. If 
the returned wpkI User ID is not present on che PG? 
key, then the User ID is added to the PGP key before 
proceeding . 

I f the WPKI User ID must be added to the PGP 
25 key, we branch off at this point and follow the normal 
PGP procedure for adding a new User ID co one's key- 
ring. The user must supply an email address for this 
User ID, because the User ID supplied by the CA will 
not have an email address. 

Since che ultimate result of this process will 
be publication of the signed key on a public keyser^er, 
the User ID must be self-signed. PGP User IDs are only 
suitable for publication if they are signed by the 
key * s owner . 

The PC next uses che user's PGP pravate key co 
sign the »'Sign this key, please . request co che CA 
(this request is asking the CA co sign the phone 



owner's PGP key, remember). This requesc was signed 
earlier by che phone's SIM card. 

earJ.ic-1- jr that Che reauescor 

This signature shows the CA tnac cne 

Che one who controls the PGP private key component, 

Ind is not sending someone else-s key for cert.f.ca- 
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The PC sends the PGP and Phone signed -Sign 
Ch^s user ID and Key, Please.- request packet with the 
corresponding PGP key up to the CA. through the estao- 
lished TLS link. Agaxn, this pacKet links the phone 
owner -s (presumably anonymous) r^ID w.th the public PGP 
Identity so Che channel must be encrypted. 

* The CA checks the PGP signature. The CA checks 

the phone key. The CA then checks in its confidential 
database for the User XO associated with the phone tha 
Signed the "Sign this Key. Please.- request^ 
n^itted PGP user ID (name portion) must match with the 
cl-s phone-s user name. This will be the case, because 
,u3t added the User ID returned by the CA for this 
,0 NTD to the PGP key we attached to the message. 

If Che submitted User ID for this phone is not 
found m Che CA'S confidential database, the 
denied, and an error massage is sent back to the C. 
For debugging purposes, this error message coula con- 
2S tain Che correct User ID, since we are operating over 
an encrypced channel. The user is informed of the prob- 
iL Via an error message displayed on PC If che name 
por-on Of the User IDs match, then the CA signs the 
PGP key with the CA key and discards the "Sign this 
30 key. Please., request with the phone NID. It then in- 
serts this information into the confidential 
The CA-signed PGP key is added to a "Pending PGP Cer 
nificace'' database on the CA. 

The CA then emails the CA-signed PGP Key to 
35 the email address specified by the user in the User ID 
that was Signed by the CA. This provides a check that 
Che email address is correct. This certificate is en- 
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crypced by che public encrypcion key of chat user. Thac 
way le Che email address nurns ouc co be wrong, and che 
key xs misrouced, ic will likely never be decrypted by 
anyone . 

The CA expects che user co decrypt and re- 
upload che signed key back up co che CA, chus proving 
chat che email address was correcc, and che person re- 
siding ac chac email address has che capability of de- 
•crypcing wich chac key. When che CA receives this key 
back from che user, che CA purges xc from che Pending 
PGP Certificace database. To overcome email delivery 
problems, periodically the CA will repeat che previous 
step lentil Che user responds or until che CA decides to • 
give up. 

When the CA receives chis key back from che 
user, che CA publishes che resulcanc signed PGP key on 
ICS PGP key server. The PGP key is signed only wich che 
LRA-verified User ID, of course. None of che ocher 
UserlDs chac che user mighc have on his PGP key are 
signed by che CA. Noce also chat che telephone NID is 
noc part of che PGP key, nor is ic published wich the 
PGP key, so we are scill proceccing che user's NID- 

relaced anonymicy. 

Figure 2 presencs one example of che flowchart 
25 of Che presenc invencion. Firsc che need for any addi- 
tional data is checked, scace 21. The addicional daca 
can be user's currenc and previously issued certificate 
or some ocher information like che name or che e-mail 
address of che user. If any addicional information xs 
30 needed Chen che user will provide it, scace 22. Then 
the request for idencif icacion is sent to che registra- 
cion authority CA, state 23. According che idencicy in- 
formation che exiscence of any previous idencicies is 
searched, scace 24. This search can be made in che pri- 
3 5 vace dacabases of che regiscracion authority or data- 
bases of ocher authorities. If any previous idencicies 
is found Chen a response is created and sent co speci- 
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fied cerminal. scane 26. If any prevxous xdencicies xs 
Poc found Chen che informacion needed . is acquired from 
Che user If che user accepts che response he or she 
Signs ic dxgically and sends ic back co regiscracion 
auchoricy, sraces 27 and 28. If any addacional guaran- 
tees are required chen chose can be acquired from ap- 
propriate authorities, stares 29 and 210. Finally che 
confirmed identity information is sent co specified re- 
ceiver, state 211. 

Figure 3 presents one example of che certiti- 
cate of che present invention. The certificate contains 
a number of informacion, which are required for che 
identification. Typically such information are certit:L- 
cace identification number, user name, users e-mail ad- 
dress, RSA/DSS keys, the fingerprint of the signature 
or of the certificate itself, the hash of che 
passphrase. the signacure. and the expiration dace of 

the certificate. 

The previous description of the preferred em- 
bodiments IS provided CO enable any person skilled m 
the art^to make or use che present invention. The vari- 
ous modifications to these embodimencs will be readily 
apparent to those skilled m the arc, and che generic 
principles defined herein may be applied to other em- 
bodiments without the use of the xnventive faculty. 
Thus, the present invention is not intended to be lim- 
ited to the embodiments shown herein but is to be ac- 
corded the widest scope consistent with the principles 
and novel features disclosed herein. 
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